Subject: 15/16 Byte Netbios Names

From: [email-masked] (Paul Brittain)
Date: Sat, 11 Jun 94 13:57:23 BST

Steve, Ravi and Robin,

Thanks for all your feedback on my suggested handling for Netbios circuits.  I
think it is possible to achieve a win-win combination of all the ideas by
recognizing that we have been addressing two different problems: name caching
and the matching of NQ/NR requests.

We should use 16-byte name significance as the default in the matching of NQ/NR
messages, with retries absorbed at the origin and issued at the target DLSw for
each (16-byte) name.   This has the advantage of limiting the number of NQ
messages to 2 for the scenario I described in the previous mail. (You can't get
any better than this without building knowledge about the specifics of LANMAN
and other Netbios stacks into the DLSw - ugh!)  It will also work for any
Netbios stack that really does use 16-byte names.

Robin's concern about the size of the name cache can be resolved by using
Ravi's  proposal for determining when to add an entry to the cache.  This would
add only one 15-byte name to the cache for the same scenario.  If the 16th byte
is printable (because it is a real 16-byte name), then a 16-byte name cache
entry is added instead.

Does this look OK to all of you?

I have attached some more detailed responses to specific points raised in your
mails below.

See you in Raleigh,

Paul Brittain
Data Connection.

------------------------------------------------------------------------------
> From: Robin Layland <[email-masked]>
> To: DLSW connect ROGlet <[email-masked]>
>
> I agree with Ravi proposal. Pauls and Steve proposal using the 16 bytes
> always will lead to problems with table size. I know this from experience. A
> network with 10,000 names will generate 30,000 to 50,000 unique 16 byte
> names. The table was big enough with 10,000. Plus it goes beyond the table
> size. Each new Netbios names causes the CANUREACHs to be sent to every
> location. Since it is highly likely that during the day the end-station will
> use a different value in the 16th byte while session are active we will lost
> the benefit of learning. Add to this is that I have seen few servers or
> client that let an end-user configure the name past eight characters. Check
> your testing and you will find bytes 9 to 15 are binary zeros.
>

True in the case of LANMAN, but I have seen standalone DOS Netbios stacks that
allow full 16-byte names so we must ensure that 16-byte names will work.  As
explained above, my proposal was really about the connection mechanism not the
caching, but we can use RAVi's proposal for the cache.

> Lets not get to far from relaity to handle possible situations that we have
> never seen. People are not out writing new netbios system code so what we

> see currently out their is what we will see in the future.
>
> The proble of someone using a nonprintable character in the 16 bytes and
> using all 16 bytes is as close to zero as you can come. Plus we should not
> lost the benefit of learning because someone out their does something that
> is really odd. It is just to unlikely besides being very difficult to do.
> .
> Robin Layland
>
> Ravi's Proposal:
>
> If the last byte is a printable character, it is probably a name where all
> 16
> bytes were used. If it is a non printable character, it is probably a name
> with 15 characters with the 16th byte used by the application. So all the
> DLSw
> implementation has to do is check for this before taking a decision to store
> the name in the cache.

As long as we define a standard meaning of 'printable' in terms of a range of
hex values (x20 - x7f?), this seems fine.

>
> If the last byte was used by an application which puts in a printable
> character
> then the worst that will happen is that we will end up using an extra entry
> for
> the same end station. But this may not happen very often as applications
> tend to use numbers which are not printable (or atleast not on the
> keyboard).
>
>

------------------------------------------------------------------------------

> From: "Steve Klein" <[email-masked]>
> To: [email-masked]
> Subject: 16/15 Character Netbios Names
> Status: RO
>
> The phenomenon that we are seeing with the magic 16th byte are
> qualified NETBIOS names.  The NETBIOS names that Paul Brittain describes
> in his (Wed, 1 Jun 94 12:28:43 BST) note for MS LANMAN look just like the
> OS/2 LAN Server/Requester names.  I asked one of the OS/2 LAN
> Server/Requester developers about it and he said that for them the 16th
> byte is a 'name type'.  A x'03' indicates a 'message name' (a user on the
> workstation) and a x'05' indicates a 'forwarded name' (name on the
> workstation being forwarded to another workstation).  For some reason
> these applications look for a forwarded name before they look for a
> 'regular' name.
>
> We have also seen applications that use the 16th byte as a resource type
> for the workstation (printer, disk, etc.).  However, there is nothing
> in the NETBIOS architecture that prevents an application from using
> all 16 bytes of the destination name field as a unique name.
>
> Paul Brittain's note shows a 6611 scenario where the 6611 handles the
> x'03' NAME_QUERY differently than the x'05' NAME_QUERY.  I agree with
> his proposed flow for the same situation (ie. one x'05' NETBIOS_NQ and
> one x'03' NETBIOS_NQ with absorption of retries at the origin DLSw and
> local retries at the target DLSw).
>
> Here are my comments on Paul's proposal for NETBIOS:
>
> >The detailed processing in this proposal is as follows:
> >
> > - When receiving a NQ from the LAN, a DLSw always treats all 16 bytes as
> >   significant in the names.  This will cause it to create two control
> >   blocks during a LANMAN circuit setup sequence, one each for the NQx05
> >   and the NQx03.
>
> I agree.  Leaving a 15 or 16 byte name configuration option will be too
> confusing to users who have no idea what convention their NETBIOS
> applications use.
>
> >
> > - Retries on a NQ on the LAN are absorbed as long as the control block
> >   still exists, otherwise they are treated as a new setup attempt.
>
> I agree.  However, you may want to say 'treated as a new SEARCH attempt'.
> The new separation of topology and circuit establishment flow has the
> NETBIOS_NQ and NETBIOS_NR as explorer only frames.  A CANUREACH and
> ICANREACH will be used to set up the circuit.
>

Fine.  I confess that my mind has not yet learnt to think in _cs and _ex
suffixes all the time!

> >
> > - Control blocks are timed out if they remain in the DISCONNECTED state
> >   (i.e. the circuit setup fails).  The timeout period is locally
> >   configurable.
> >
>
> We can leave the amount of time that a search is outstanding up to the
> origin DLSw based on a configured value, available memory, or whatever
> it chooses.

Agreed.  This was what I had intended.

>
> > - The target DLSw behaves similarly for each NETBIOS_NQ received over
> >   TCP/IP.
> >
>
> I assume you mean that the target DLSw will do local retries of the
> NETBIOS NAME_QUERY.

Yes.

>
> > - When it receives a NR over the LAN, the target DLSw tries to match it
> >   against any outstanding NETBIOS_NQ control blocks using 16 byte name
> >   significance.  If this fails, it could (optionally?) try for a 15 byte
> >   match.
>
> I think it should do the match based on all 16 bytes of name since the
> NAME_RECOGNIZED could contain a session identifier for that particular
> name type.
>

This works for any Netbios stack that echoes the same value in the 16th byte of
a name in the NR as was specified in the NQ.  I was worried that it may be
possible for a Netbios stack to vary this value to provide some form of
feedback - but I don't actually know of any such usage and am happy to drop the
15-byte fallback if no-one knows of any such Netbios stack.

> >
> > - If a match is found, the target DLSw sets up whatever circuit control
> >   block it needs in order to be able to send a NETBIOS_NR back to the
> >   origin DLSw with the full circuit ID specified.
>
> The NETBIOS_NQ_ex and NETBIOS_NR_ex do not establish circuits.
>
> >
> > - On receipt of a NETBIOS_NR, the origin DLSw matches the name specified
> >   in exactly the same way as the target searched for a match.  If a match
> >   is found, it sends the NR on the LAN, sets up a circuit control block
> >   and sends an RA with the fully specified circuit ID.  If no match is
> >   found, the origin DLSw returns a HALT_DL_NO_ACK to tidy up the circuit.
>
> Again, no circuit setup should be occurring.
>
> >
> > - Circuit setup then follows the usual FSM as the SABME and UA flow.
> >
> > - Any NQ/NR control blocks that were set up but never resolved (e.g. the
> >   NQx05 for LANMAN) are eventually timed out and discarded.
>
> I agree.  The new NETBIOS flow has a CANUREACH_cs being generated by
> the SABME (the first directed frame) to initiate a circuit.
>
> >
>
> Steve
>